home *** CD-ROM | disk | FTP | other *** search
/ Night Owl 6 / Night Owl's Shareware - PDSI-006 - Night Owl Corp (1990).iso / 016a / quartrd.zip / IA.TEC < prev    next >
Text File  |  1991-12-19  |  11KB  |  193 lines
  1.  
  2. ID:IA  QEMM-386 and Keyboard Behaviour
  3. Quarterdeck Technical Note #221
  4. by: Michael Bolton
  5. December 17, 1991
  6.  
  7.                     QEMM-386 AND KEYBOARD BEHAVIOUR
  8.  
  9. INTRODUCTION
  10. ============
  11.  
  12.      Users sometimes experience "sticky shift keys" under QEMM -- the 
  13. symptom is that the Shift, Control, or NumLock keys appear to take 
  14. effect even though they have not been pressed.  The IA parameter to QEMM 
  15. can sometimes fix this problem.  To use it, simply add IA to the end of 
  16. the QEMM line in CONFIG.SYS as follows:
  17.  
  18.      DEVICE=C:\QEMM\QEMM386.SYS <your other parameters> IA
  19.  
  20.      If this does not work, QEMM can provide no other solution to the 
  21. problem.  When IA is used, QEMM does not affect keyboard activity.
  22.  
  23. THE REAL CAUSE
  24. ===============
  25.  
  26.      The probable source of the difficulty is a program that intercepts 
  27. or redirects Interrupt 9, which is responsible for detecting keyboard 
  28. activity.  TSRs often do this, especially those which pop up under the 
  29. control of a hot key, or those which monitor or accelerate keyboard 
  30. performance.  Application programs can occasionally exhibit this 
  31. behaviour as well.  Such a program reads the keyboard, and then decides 
  32. whether the key is important to its operation: if it is, the program 
  33. interprets the key and performs one of its own functions; if not, the 
  34. program passes the keyboard event to the previous owner of INT 9.  Note 
  35. that several programs may be attempting to monitor the keyboard this 
  36. way, and that several programs may be inspecting the keystroke before it 
  37. eventually reaches the system ROM BIOS, which is the original handler of 
  38. INT 9.
  39.      Before the appearance of the PC-AT architecture, a program could 
  40. read the keyboard by inspecting the keyboard port, and then resetting 
  41. the keyboard. After the reset, a new key could be put into the keyboard.  
  42. On the PC-AT and later machines (i.e. since 1985), the correct method is 
  43. to disable the keyboard, read the keyboard port (which would allow a new 
  44. key to be put into the keyboard port if the keyboard had not been 
  45. disabled by the first step), reset the keyboard (which does not have any 
  46. particular function in this newer way of doing things), and then re-
  47. enable the keyboard (which allows a new key to be put into the port). To 
  48. further complicate matters, machines that have a PS/2-style mouse must 
  49. disable that as well, but it is dangerous to do so if the mouse port 
  50. does not exist!  In fact, programs should be using another method (INT 
  51. 15, Function 4F) to read the keyboard -- which avoids all of these 
  52. problems entirely.
  53.      Many programs apparently do not implement the later, correct method 
  54. of reading the keyboard.  Consequently, the old-style read-and-reset 
  55. method allows a new key to come in, perhaps before the program has had a 
  56. chance to pass the first key to the previous interrupt handler.  By the 
  57. time a decision has been made to pass the key along, a different key may 
  58. be in the keyboard port.
  59.      Keyboards do pace the keys they put in the keyboard port, and so if 
  60. not too much time elapses between reads of the port, the correct key 
  61. will be passed.
  62.      Several things can affect this:
  63.  
  64.           1) If some I/O ports that are accessed during this period are 
  65.      trapped by QEMM, then that slows down the sequence of code, 
  66.      increasing the likelihood that a new key may be in the keyboard 
  67.      port when it is read by the next program down the chain.
  68.           Programs which read the keyboard read I/O port 64 as part of 
  69.      the process.  Port 64 controls the state of the the A20 address 
  70.      line, which must be enabled for access to extended memory.  When 
  71.      the A20 bit is enabled, programs may also read and write to 
  72.      extended memory addresses instead of wrapping to the bottom of 
  73.      conventional memory addresses.  By default, QEMM traps port 64 to 
  74.      detect programs which are attempting to manipulate the state of the 
  75.      A20 line, which unfortunately shares its I/O port with the keyboard 
  76.      controller. (The logic underlying the decision to place such a 
  77.      crucial piece of system control hardware on the keyboard controller 
  78.      is lost in the mists of time.  All that is known is that there was 
  79.      a spare bit in one of the registers on the keyboard controller, and 
  80.      a need for a place to put the bit that would enable and disable the 
  81.      A20 line.)
  82.           The IGNOREA20 (IA) parameter instructs QEMM to refrain from 
  83.      trapping this I/O port, and thus causes QEMM to ignore the keyboard 
  84.      completely.  Note that on Micro Channel machines, QEMM does not 
  85.      monitor port 64; it monitors port 92 instead (since port 92, rather 
  86.      than port 64, is used to control the state of the A20 line on Micro 
  87.      Channel machines), and therefore IA will have no effect on Micro 
  88.      Channel IBM PS/2s or other MCA machines.
  89.           2) QEMM puts the processor into Virtual 86 mode when QEMM is 
  90.      in an ON state -- essentially when expanded memory or High RAM is 
  91.      being provided.  The same is true of any 386 expanded memory 
  92.      manager --whether QEMM, DOS 5's EMM386, Compaq's CEMMP, or the 
  93.      like; Virtual 8086 mode is necessary to provide expanded memory or 
  94.      High RAM. In V86 mode, many instructions take longer than in real 
  95.      mode, and interrupts themselves are slowed down, again increasing 
  96.      the possibility that a keyboard event might be missed. In this 
  97.      case, your 386 memory manager contributes to the overhead of 
  98.      processing interrupts, but it is not actually causing the problem.
  99.           3) The above two scenarios are not usually a problem with most 
  100.      keys, simply because people do not type fast enough to have another 
  101.      key available when the next TSR (or the BIOS) tries to read a key.  
  102.      But on the newer 101-key keyboards -- which first appeared in 1987, 
  103.      and which have separate number and cursor keypads -- the cursor pad 
  104.      keys are special when NumLock is on.  A single Arrow key on the 
  105.      cursor pad with Numlock on generates six keyboard interrupts on the 
  106.      downstroke and six more on the upstroke.  They are:
  107.  
  108.           1: "A New-Keyboard-style key will be the next key"
  109.           2: Left shift down
  110.           3: "A New Keyboard key coming next"
  111.           4: Arrow down
  112.           5: "A New Keyboard key coming next"
  113.           6: Left shift up
  114.  
  115.         These come in rapid succession, controlled by the keyboard pace 
  116.      rate. If there is a misbehaved keyboard interrupt handler in the 
  117.      chain, one of these keyboard interrupts might get lost by the time 
  118.      it reaches the BIOS handler. If the interrupt that is lost is the 
  119.      fake upshift, the BIOS will think the shift key is still down.
  120.  
  121.      The IA parameter to QEMM reduces the overhead on reads of port 64, 
  122. and thus might improve the situation such that the problem disappears --
  123. which will alleviate situation (1) above.  Removing QEMM will alleviate 
  124. situation (2) above, but this is not a likely to be a particularly 
  125. viable solution, since you lose all of the benefits of 386 memory 
  126. management -- and therefore most of the benefits of the 386 
  127. architecture.  Note that other 386 memory managers will probably cause 
  128. your system to exhibit similar behaviour.
  129.      DESQview does hook the keyboard interrupt, but it uses the proper 
  130. technique to do so.  QEMM does not hook the keyboard interrupt, and has 
  131. only an incidental effect on the keyboard as discussed above -- QEMM 
  132. adds a small amount of overhead to the system generally, and therefore 
  133. can appear to be the "cause" of the problem.  However, neither QEMM nor 
  134. DESQview, in and of themselves, will cause sticky shift keys; the direct 
  135. cause of invisibly held-down shift keys is determined by some other 
  136. aspect of your system.
  137.  
  138. IDENTIFYING THE CAUSE
  139. =====================
  140.  
  141.      Manifest can help you determine which program or programs are 
  142. hooking INT 9.  Go into Manifest by typing MFT at the DOS prompt.  Press 
  143. F for First Meg, I for Interrupts, and F3 for list by number.  In the 
  144. middle of the list, you should see:
  145.  
  146.      INT 09: Keyboard Event      0C43:7114 STINKKEY
  147.  
  148.      What you see as the values displayed above will differ.  The above 
  149. address and program are totally fictitious, and where the interrupt is 
  150. pointing may be affected by the STACKS settings in CONFIG.SYS.  You 
  151. should ensure that the line STACKS=0,0 appears in CONFIG.SYS, so that 
  152. device drivers which have hooked INT 09 will display on this list.  This 
  153. will be necessaary if Manifest is reporting that the owner of INT 09 is 
  154. "DOS Stacks".
  155.      In the example above, INT 09 is being handled by a TSR called 
  156. STINKKEY; it is probably our culprit.  Try removing the TSR (or device 
  157. driver) that is hooking INT 09, and see if that cures the problem.  If 
  158. not, continue removing TSRs or device drivers that are hooking INT 09 
  159. until the offender is found.
  160.      If the problem happens from within an application, load Manifest as 
  161. a TSR, and pop it up from within the application that exhibits the 
  162. problem.  Note that the application with the problem must be running in 
  163. text mode (not graphics mode) for Manifest to pop up.
  164.  
  165.  
  166. FIXING THE PROBLEM
  167. ==================
  168.      
  169.      Temporary relief from sticky shift keys can sometimes be provided 
  170. by tapping the key that appears to be stuck.  The BIOS will then see the 
  171. proper state of the shift key, and things should work normally.
  172.      Keyboards have on-board controllers which determine some of the 
  173. behavior of the keyboard.  Specifically, the keyboard controller governs 
  174. what scan code is generated by each key, and how much time should elapse 
  175. between keyboard interrupts when a keystroke generates multiple 
  176. interrupts.  Therefore, different keyboards might pace differently, and 
  177. so exchanging the keyboard for another might affect the problem -- and 
  178. possibly improve things.  One chipset that we are aware of has in its 
  179. setup an option for a "Fast A20 Gate Enable"; toggling this setting has 
  180. helped some users, and similar options on other chipsets could help. 
  181. Some companies claim that BIOS upgrades can help alleviate sticky shift 
  182. keys.
  183.      All of these are side issues, however.  The actual problem is that 
  184. a program in keyboard interrupt chain -- probably the last one loaded --
  185. is not reading the keyboard properly.  The simplest solution may be to 
  186. remove the offending program.  If you require that program for a 
  187. definite purpose, and if no other well-behaved substitute can be found, 
  188. consult the program's authors or publishers for assistance.
  189.  
  190.       * * * Copyright (c) 1991, Quarterdeck Office Systems * * *
  191.                  * * *   E N D   O F   F I L E  * * *
  192.  
  193.